Today, the pre-boot environment is characterized by initiating power to a given platform, and fetching a set of code from the platform firmware to commence boot in the processor. For an extensible firmware interface (EFI) compliant system, there is firmware in the flash part of the computing system that executes, and germinates an EFI operational environment. EFI is characterized by a set of boot services, including memory allocation, time, stall, and setting time. In addition, EFI is characterized by a set of protocols which are installable interfaces identified by globally unique identifiers (GUIDs), which are typically 128 bits long. The various protocol capabilities or services can be published for global use. For example, if the computing device has a USB (universal serial bus), there is a USB protocol that a driver will publish. In EFI, today, there is a class of image, or executable, called an EFI driver. An EFI driver is a portable executable, common object file format (PE/COFF) image. PE/COFF is similar to the image format used by Microsoft® Corporation for Windows™ drivers. The EFI 1.1 Specification has been released/defined to support EFI, and is currently available on the Internet at http://developer.intel.com/technology/efi.
Currently, for new hardware such as a new disk controller, for example, there is an abstraction to support communication with the disk, called the block input/output (I/O) protocol. For example, if a new disk controller chip is designed that communicates to a disk in a certain way, the chip vendor must write an EFI driver that would be a single PE/COFF binary image. This image is loaded by the system's EFI core and it would publish a block I/O protocol. This block I/O protocol defines read, write and reset services. This driver implements these particular services for the chip. If the chip needs to set a certain bit for a read, for instance, the driver provides a function to accomplish this operation. The driver abstracts the service, so there are things such as file system drivers that search for the block I/O protocol and can create a file system instance similar to the Microsoft File Allocation Table (FAT). This block I/O protocol is an abstraction allowing a software-only file system driver. The value in the abstraction is that a system can support various interfaces such as the small computer system interface (SCSI), integrated drive electronics (IDE), a block abstraction on USB, IEEE 1394, etc. It is under the purview of the particular driver writer how to support the read, write, and reset service for block I/O, for example. New or different hardware can be plugged in; all that is needed is a new driver.
EFI is a relatively new framework. The class of EFI compatible drivers in the market is smaller than legacy drivers. EFI compatible drivers have only been developed in the last few years. Device vendors are often not willing to develop EFI drivers when there are as yet only a small number of EFI compliant systems in use. The vendors want to keep their resources for developing drivers for systems that are shipped to 100,000 rather than 10,000 customers. Windows™ and GNU Linux have many existing drivers. Some of the success enjoyed by an OS is due to the number of compatible drivers that exist for various hardware platforms for running the OS.
The boot process for EFI compatible systems varies from a legacy system. Drivers are in abundance for the pre-boot phase of legacy systems running a basic input/output system (BIOS). EFI-compatible drivers are few. During pre-boot of EFI-compatible systems, the EFI must boot the OS. During pre-boot, the processor needs to know how to communicate with the hardware in order to complete the boot. The OS driver that knows how to communicate with the hardware, for instance a hard disk, cannot be used in the pre-boot stage in current systems.